home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 133_01 / e.doc < prev    next >
Text File  |  1980-01-01  |  51KB  |  1,261 lines
  1. The  e   screen editor                             Page 1
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.                                      
  13.                                   eeeee      
  14.                                  ee    ee 
  15.                                 ee      ee
  16.                                eeeeeeeeeee
  17.                                ee         
  18.                                 ee        
  19.                                  eeeeeeeee
  20.  
  21.  
  22.                   TUTORIAL GUIDE AND IMPLEMENTATION MANUAL
  23.  
  24.  
  25.  
  26.  
  27.  
  28. The   e   screen  editor  is full-screen editor designed  for  creating  and 
  29. modifying the source text of programs.  It is not, and it is not intended to 
  30. be, a word processor.
  31.  
  32.  
  33.  
  34.  
  35.  
  36. It is released through the C Users Group for private non-profitmaking use by
  37.  
  38.                               G. Nigel Gilbert
  39.                                  MICROLOGY
  40.  
  41.  
  42.  
  43.  
  44.                         Version 4.8     October 1984
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71. The  e   screen editor                             Page 2
  72.  
  73.  
  74. Contents
  75.  
  76. 1.   Prerequisites
  77.  
  78. 2.   Introduction
  79.  
  80. 3.   Development history
  81.  
  82. 4.   Why  e  was written
  83.  
  84. 5.   How  e  works
  85.  
  86. 6.   Using  e
  87.  
  88. 7.   Implementing  e  on your terminal
  89.  
  90. 8.   Changing the default settings of the options
  91.  
  92. 9.   Compiling and loading  e
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.                               1. Prerequisites
  102.  
  103. The  editor is written in the programming language C and the source code  is 
  104. available  in the public domain for non-profit use.   It is recommended that 
  105. you also have to hand a copy of the BDS C compiler,  version 1.50 or  later, 
  106. if  you need to reconfigure the editor to suit your terminal and your choice 
  107. of default option settings.
  108.  
  109. The  editor can be configured simply to run under CP/M with  any  moderately 
  110. sophisticated  terminal.   The  following screen control functions  must  be 
  111. available  with the terminal:  clear to end of line,  clear to end of  page, 
  112. line insert, and line delete.  It is probably not worth using or adapting  e  
  113. to run on terminals that do not support these functions (among the terminals 
  114. which  DO support these functions are:  the TVI  910,  912,  920,  925,  950 
  115. series,  Hazeltine 1420,  1500, Executive and Esprit series, ADM-31 (but not 
  116. the  ADM-3a),  DEC VT52 and VT100,  ADDS range,  Visual 50 and 55 and  other 
  117. terminals which offer emulations of these).
  118.  
  119. Also required is CP/M,  version 2, or CP/M 3.1 (CP/M Plus), and at least 48K 
  120. (and preferably 56K) of RAM.  Other versions of CP/M might well do.
  121.  
  122.  
  123.  
  124.                               2. Introduction
  125.  
  126. This document has sections on:
  127.  
  128.      the  'philosophy'  of e - why it was written to work the  way  it  does 
  129.           (sections 3, 4 and 5)
  130.      using e (section 6)
  131.      implementing  e (sections 7, 8, and 9)
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141. The  e   screen editor                             Page 3
  142.  
  143.  
  144.  
  145.  
  146.  
  147.                            3. Development history
  148.  
  149. e was written over a period of about two years to satisfy my own need for  a 
  150. decent  screen editor to use for programming,  primarily in C,  but also  in 
  151. FORTRAN  and Pascal.   During that time,  it has developed and  changed.   I 
  152. expect  that it will continue to do so,  and hope that other users will keep 
  153. in contact with me about what they think of it, what changes they make to it 
  154. and how it could be improved.  
  155.  
  156. I can be contacted at:
  157.  
  158.           G. Nigel Gilbert
  159.           MICROLOGY
  160.           4 Deanery Road
  161.           Godalming GU7 2PQ
  162.           Surrey
  163.           England
  164.  
  165.  
  166.  
  167.                            4. Why  e was written 
  168.  
  169. The design of e was determined largely by my own specific needs.   I already 
  170. possessed  a  copy  of  WordStar,  the  well-known,  massive  and  generally 
  171. excellent  word processing package.    I also possessed a copy of the  well-
  172. known and entirely excellent BDS C compiler.   Unfortunately, the two do not 
  173. mesh well together.  In practice, programming in C (or in any other compiled 
  174. language)  requires  one to edit a program file,  run the file  through  the 
  175. compiler,  locate  errors,  then re-edit the file to make  corrections,  and 
  176. repeat all this a large number of times.   The faster the cycle can proceed, 
  177. the faster is program development.   However,  because WordStar is a big and 
  178. powerful  package,  with two overlays to read off disk into memory,  it  can 
  179. take over 25 seconds from the moment the command line is typed to being able 
  180. to  edit  the program text.   Moreover,  the C compiler,  like many  others, 
  181. reports  syntax errors by line number;  WordStar has no command to move  the 
  182. cursor to a specified line number.   All in all, WordStar is great for text, 
  183. and not much good for programs.
  184.  
  185. I resolved, therefore, to write an editor more adapted to my needs.  Such an 
  186. editor  would  have  the  following  characteristics  (in  rough  order   of 
  187. priority):
  188.  
  189.     Small run file, with no overlays
  190.     No initial menu - one would go straight into editing the text
  191.     A command to jump to a given line number
  192.     Random access to the text;  as far as possible, it should be as quick to 
  193.      move from line 500 to line 1 as from line 1 to line 500
  194.     As few 'modes' as possible - I don't like editors (such as, for instance 
  195.      the  UCSD editor) where one can only insert in the 'insert'  mode,  and 
  196.      only delete in the 'delete' mode 
  197.     No (unreasonable) limit on the size of files which can be edited
  198.     As  crash proof as possible - including guards against BDOS  errors  and 
  199.      disk and directory full errors
  200.     Auto-indent feature for structured programming languages
  201.     Capability  of  listing  selcted portions of programs  to  the  printer, 
  202.      whilst remaining inside the editor
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211. The  e   screen editor                             Page 4
  212.  
  213.  
  214.  
  215. e  does all of these.   On the other hand,  there are a number of facilities 
  216. which  other  editors possess,  but which  e  does not have.   They are  all 
  217. features which, if implemented, would conflict with one or more of the above 
  218. 'desirables'.   An  editors  is  the kind of the thing  for  which  personal 
  219. preferences are important and varied,  and thus your favorite feature may be 
  220. in the list below, rather than the list above.  If so, you can always have a 
  221. go implementing it.  (If you do, I'd be glad to have a copy, and so probably 
  222. would the User Group).
  223.  
  224.     Macros and multiple commands executed repeatedly (in my view,  these are 
  225.      more  appropriate to a batch,  rather than an interactive editor;  and, 
  226.      anyway,  such  commands  are  difficult to formulate so  that  they  do 
  227.      exactly what is wanted and neither more nor less)
  228.     Wild  characters and regular expressions in defining search strings  for 
  229.      the  Find and Alter commands (possible to implement,  but would  reduce 
  230.      the searching speed significantly)
  231.     An  'Overwrite'  mode  as well as an 'Insert' mode (see  comments  above 
  232.      about modes)
  233.     Word processing capabilities,  such as word wrap and re-formating (I use 
  234.      WordStar)
  235.     Block  moves  of arbitrary blocks,  rather than just blocks of  complete 
  236.      lines (fine, but the coding is hair-raising)
  237.  
  238. At one time or another, I've tried all these latter features, but eventually 
  239. given up or thrown them out as unnecessary or unproductive.
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. The  e   screen editor                             Page 5
  282.  
  283.  
  284.                               5. How  e  works
  285.  
  286. The  above  list  of  desirables more or  less  dictated  the  basic  design 
  287. principles  of   e.   For  instance,  the need to get to a  particular  line 
  288. suggested  that  the  text being edited should be  organised  in  lines  (as 
  289. opposed to a continuous block of text,  including end-of-line markers).  The 
  290. former  organisation is that adopted by  e  (and by EDIT-80);  the latter by 
  291. ED  and  WordStar.   The choice has a profound impact on the  style  of  the 
  292. resulting editor.
  293.  
  294. Since  text lines are